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Beschreibung 

Programmierschittstellen zu einer Vermittlungsstelle 

1. Welches technische Problem wird durch die Erfindung 
gelost ? 

Vermittlungsstellen in Telef onnetzen sind typischerweise 
geschlossene Systeme, d.h. sowohl die Realisierung der 
unterstutzten Funktionen, wie z.B. Aufbau von Rufen, 
Vergebuhrung, Statistik, als auch die Hardwarebasis sind 
herstellerspezif isch- Netzbetreiber von 

Telekommunikationsnetzen mtissen daher ihre spezifischen 
Anf orderungen an Vermittlungsstellenf unktionen mit den 
Herstellern absprechen, die diese dann im Auftrag der 
Netzbetreiber realisieren - 

In zunehmendem Mafi^e fordern daher die Netzbetreiber, dafi die 
Telekommunikationsausruster sowohl als Basis Ihrer 
Vermittlungsstellen kommerzielle Plattformen verwenden als 
auch die Funktionen auf diesen Plattformen fur eine Steuerung 
von "aulien" offnen, d.h. der Netzbetreiber selbst oder von 
ihm beauftragte Programmierer sollen iiber geeignete 
Schnittstellen selbst die Funktionen der Plattformen steuern 
Oder erweitern konnen. 

Einer der Hauptgrunde fur diese Forderung nach Offenheit, ist 
der Konkurrenzdruck der Netzbetreiber in liberalisierten 
Netzen. Die Netzbetreiber versuchen sich daher primar durch 
neue attraktive Mehrwertdienste voneinander zu 

dif ferenzieren. Dabei ist es wichtig, Betreiberspezif ische 
neue Mehrwertdienste schnell einfuhren zu konnen. Die 
Netzbetreiber fordern daher offene Schnittstellen, damit sie 
selbst Mehrwertdienste implementieren konnen. 
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2. Wie wurde das genannte Problem bisher gelost ? 

Wie oben erwahnt, waren bisher Vermittlungsstellen 
geschlossene Systeme, d.h. offene APIs sind nicht vorhanden. 
Neue Dienste der Vermittlungsstellen haben die 
Telekommunikationsausruster entwickelt und kundenspezif ische 
Entwicklungen im Auftrag eines Netzbetreibers waren aus 
wirtschaf tlichen Grunden nur in begrenztem MaShe moglich. 
Daneben wird von vielen Vermittlungsstellen eine fur 
Dienstesteuerung standardisierte SS7- Protokollschnitts telle 
zu externen IN-Systemen unterstutzt (INAP - Intelligent 
Network Application Protocol) . Von vielen IN-Herstellern wird 
fur diese IN-Systeme ein Service Creation Environment 
angeboten, das eine IN-Dienst-Programmerstellung durch den 
Netzbetreiber selbst oder eine von ihm beauftragte SW~Firma 
ermoglicht- IN Service Creation Systeme haben sich am Markt 
nicht durchgesetzt - Als ein wesentlicher Grund daflir wird 
u.a- die bei der Nutzung dieser Systeme erfahrene Komplexitat 
der Diensteprogrammierung angesehen . 

Seit kurzer Zeit gibt es Bemuhungen, zusatzlich zu dem 
standardisierten INAP - Protokoll und anderen 

standardisierten Protokollen in offentlichen 

Telekommunikationsnetzen auch Programmierschnittstellen 
(Application Programming Interfaces, APIs) fiir 
Telekommunikationsanwendungen zu standardisieren . Zunachst in 
Interessengruppen der Industrie, z.B. PARLAY, JAIN, und nun 
auch in internationalen Standardisierungsgremien wie 3GPP, 
ETSI und ITU-T. Diese standardisierten APIs bilden die 
Funktionalitat der unterliegenden Protokolle als 

Programmierschnittstelle ab. Inwieweit sich die Nutzung 
dieser APIs am Markt durchsetzen wird, ist of fen. 
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3. In welcher Weise lost Ihre Erfindung das angegebene 
technische Problem ? 

Gemali der Erfindung wird eine klassische Vermittlungsstelle 
mit einer zusatzlichen Plattform auf Basis kommerzieller 
Hardware (HW) und Software (SW), z.B. das Standard Operating 
System UNIX, erganzt, auf der spezielle Module 
(Applikationsblocke) implementiert werden, deren Funktionen 
extern iiber offene APIs gesteuert werden kbnnen. Diese 
Plattform erlaubt so dem Netzbetreiber die Entwicklung 
eigener Telef onmehrwertdienste in einer kommerziellen SW 
Umgebung auf der Basis von Application Programming Interfaces 
(API ) zu Vermittlungsstellenf unktionen . Vermittlungsstelle 
und kommerzielle Plattform kommunizieren uber eine interne 
Schnittstelle, die nicht standardisiert ist und deren 
Funktionalitat sich nach den Anf orderungen der zu 
untersttitzenden SW-Module auf der kommerziellen Plattform 
richtet. Auf der kommerziellen Plattform konnen 
unterschiedliche Applikationen implementiert werden : 
Protokollumsetzungs-Applikationen, die die standardisiert en 
APIs anbieten konnen und andere Applikationen, die nicht- 
standardisierte APIs anbieten konnen. 

Ein Unterschied und Vorteil des erf indungsgemaften Verfahrens 
gegenuber existierenden IN SCEs und anderen Systemen, die nur 
iiber standardisierte Protokoll-Schnittstellen zu 

Vermittlungsstellen verfiigen, liegt in der Moglichkeit , iiber 
die interne Schnittstelle zwischen kommerzieller Plattform 
und Vermittlungsstelle grundsatzlich freien Zugang zu alien 
Vermittlungsstellenf unktionen zu haben und diese fur die 
Implement ie rung der erf indungsgemalien Applikationen auf der 
kommerziellen Plattform nutzen zu konnen. 

Ein zweiter Unterschied des erf indungsgemaften Verfahrens 
gegenuber existierenden IN SCEs und anderen Systemen, die nur 
standardisierte APIs bereitstellen, liegt in der Idee, nicht- 
standardisierte APIs zu hoherwertiger Dienstef unktionalitat 
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zur Verfugung zu stellen, wie z.B. den automatischen Aufbau 
einer Verbindung zwischen zwei PSTN-Teilnehmern, den 
automatischen Aufbau einer Telef onkonf erenz zwischen mehreren 
Teilnehmen, das Buchen einer automatischen Telef onkonf erenz 
fiir einen bestimmten Zeitpunkt. 

Jeder dieser Dienstapplikationsblocke hat uber die interne 
Schnittstelle Zugriff zu den Call Processing Funktionen der 
Vermittlungsstelle . Die Grundf unktion eines 

Dienstapplikationsblocks ist fest definiert, wie z.B. Aufbau 
einer Verbindung im PSTN zwischen zwei Teilnehmern die iiber 
eine E.164 Adresse erreicht werden konnen inklusive dem 
Anlegen einer Begriiliungsansage oder Initialisierung von 
Gebuhrentickets fiir jeden Teilnehmer in der 

Vermittlungsstelle . 

Je Dienstapplikationsblock ermoglichen offene APIs das 
Aktivieren der jeweiligen Dienstf unktionen sowie die 
Steuerung einzelner Leistungsmerkmale . Beispielsweise konnte 
fur den Dienstapplikationsblock "Automatischer Aufbau einer 
Verbindung zwischen zwei PSTN-Teilnehmern" explizit steuerbar 
sein, welcher der beiden Verbindungsteilnehmer die Gebuhren 
ubernimmt, ob zur BegruBung eine Standardansage oder eine 
personliche Ansage gespielt werden soli (erfordert 
Ubertragung der Adresse und Identif ikation der personlichen 
Ansage) oder ob uber das API Statusinf ormationen der 
Verbindung zuriickgemeldet werden sollen (z.B. Teilnehmer 
besetzt ) 

Das erf indungsgemafiien Verfahren beinhaltet also den Ansatz, 
die Call Processing Funktionen einer Vermittlungsstelle nicht 
direkt uber APIs nach auiien zu offnen, sondern zunachst 
Dienstapplikationsblocke auf der zur Vermittlungsstelle 
gehorenden kommerziellen Plattform zu definieren, in denen 
das dienstspezif ische Interworking mit den existierenden 
Netzfunktionen gelost wird und deren Funktionen uber offene 
APIs gesteuert werden konnen. Netzbetreiber konnen diese 
Dienstapplikationsblocke beliebig aktivieren und kombinieren 
und so neue Mehrwertdienste kreieren. Dabei kann die 
eigentliche Dienstlogik des vom Netzbetreiber erstellten 
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Mehrwertdienstes auf einem beliebigen Server im Netz liegen. 
Die Dienstapplikationsblocke mit ihren definierten APIs 
dienen dem Netzbetreiber dabei als Bausteine zur 
Implementierung eigener Mehrwertdienste (siehe 

Ausf uhrungsbeispiel unter 5.) 

Das Interworking der Dienstapplikationsblocke untereinander 
wird durch einen sogenannten Session Manager 
Applikationsblock unterstutzt. Alle Applikationsblocke, die 
viber ihr API aktive Dienstanf ragen bearbeiten, nehmen eine 
Registrierung fur jeden aktiven Dienstnutzer im Session 
Manager vor. Der Session Manager bietet dafur ein internes 
API an. Wird eine Dienstanf rage beendet, erfolgt eine 
Deregistrierung . Der Session Manager hat somit jeweils ein 
aktuelles Abbild aller aktiven Diensteanf ragen . Seine Daten 
konnen von jeder Applikation gelesen werden, und unterstutzen 
so das Interworking zwischen verschiedenen 

Dienstapplikationsblocken . 

Ein wesentlicher Vorteil dieses Verfahrens ist, daft der 
Anwender der APIs zu Dienstapplikationsblocken keine 
Detailkenntnisse uber existierende Netzf unktionen haben muB . 
Insbesondere sind auch alle Details des jeweiligen 
Signalisierungssystems des Basisnetzes auf der Ebene des API 
Nutzers vollstandig transparent und das interne Zusammenspiel 
zwischen Vermittlungsstelle und Applikationsblock deckt alle 
moglichen Interworkingf alle ab. Dieses Verfahren erlaubt die 
Definition von robusten und leicht handhabbaren APIs, da der 
festgelegte Umfang jedes Dienstapplikationsblocks bzw. APIs 
mogliche Fehlerfalle einschrankt und vom Hersteller 
ausgetestet werden kann . 

Im Gegensatz zu den erf indungsgemaften APIs zu hoherwertigen 
Dienstapplikationsblocken basieren die standardisierten APIs 
(PARLAY, JAIN, 3GPP, u.a.) auf dem Ansatz, 

Protokollf unktionen abzubilden, Diese APIs sind sehr komplex 
und erfordern die Obertragung bzw. Steuerung von sehr vielen 
Steuerinformationen. Die Realisierung von Mehrwertdiensten 
auf Basis dieser APIs erfordert Telekommunikationsnetz- 
Expertenwissen . 
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Durch die Erganzung einer klassischen 

Vermitt lungs stellenarchitektur mit einer kommer ziellen 
Plattform, iiber die APIs zu den Vermittlungsstellenf unktionen 
zur Verfugung gestellt werden, ist es leichter moglich, die 
APIs auf Basis der state-of-the Art obj ektorientierten SW- 
Technologien wie CORBA, JAVA RMI Oder DCOM zu realisieren. 
Bisherige Vermittlungsstellen basieren oft auf alteren SW~ 
Technologien (z.B. CHILL, ASSEMBLER) die eine Offnung iiber 
objektorientierte basierte APIs erschweren. 

Durch die Konzeption von nicht-standardisierten, offenen APIs 
zu hoherwertigen Dienstapplikationsblocken auf dieser 
kommerziellen Plattform wird der Kreis der potentiellen 
Anwender von Telekommunikations-APIs erweitert auf Personen 
ohne Detailkenntnisse iiber Telekoiranunikationsnetzf unktionen - 

Im folgenden wird die Erfindung nochmals anhand der Zeichnung 
erlautert, die eine Figur umfaftt, 

Die Figur zeigt die prinzipielle Funktionsauf teilung zwischen 
der Vermittlungsstelle mit integrierter kommerzieller 
Plattform, die offene APIs anbietet (Backend Server) und und 
den externen Applikationsservern, die diese APIs nutzen 
(Frontend Server) . 

Die kommerzielle Plattform enthalt mehrere Applikationsblocke 
mit fest definiertem Funktionsumf ang, die mittels offenen 
APIs gesteuert werden konnen . Die Funktionen der 
Applikationsblocke verwenden iiber eine interne Schnittstelle 
die Core Call Control Funktionen der unterliegenden 
Vermittlungsstelle - 

Die Mehrwertdienste des Netzbetreibers werden auf separaten 
Applikationsservern im Netz realisiert. Dabei verwenden sie 
die offenen APIs der kommerziellen Plattform um Aktionen im 
Basisnetz zu initiieren (z.B. Aufbau einer Verbindung 
zwischen zwei Teilnehmern) oder iiber Ereignisse im Basisnetz 
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informiert zu werden (z.B. Teilnehmer besetzt, ankommender 
Ruf ) . Die offenen APIs werden auf Basis von CORBA genutzt - 
damit ist die Realisierung der SW auf den Applikationsservern 
als auch dessen HW unabhangig von SW und HW der kommerziellen 
5 Plattform. 

Abkiirzungen/Ref erenzen : 

API Application Programming Interface 
CORBA Common Object Request Broker Architecture 
10 DCOM Distributed Component Object Model 
IN Intelligent Networks 

INAP Intelligent Network Application Protocol 

(standardisiert bei ETSI und ITU-T) 
JAIN Industriekonsortium (von der Firma SUN geleitet) : 
15 www. java . sun . com/products/ jain/ 

PARLAY Industriekonsortium: www.parlay. org 

PSTN Public Switching Telecommunication Network 

RMI Remote Message Invocation 

SCE Service Creation Environment 
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Patentanspruche 

1. Vermittlungsstelle , mit 

einer zusatzlichen Plattform^ die auf kommer zieller HW und SW 
5 basiert und ein oder mehrere SW-Module enthalt, die externen 
Rechnern uber offene Schnittstellen (API) Applikationen mit 
bestimmten Funktionen zur Verftigung stellen, wobei die 
genannten SW-Module zur Durchfiihrung der genannten Funktionen 
interne Schnittstellen zu den Call-Control-Funktionen der 
10 Vermittlungsstelle benutzen, 

2. Vermittlungsstelle nach Anspruch 1, 
dadurch gekennzeichnet^ dali 

/^||^^' die genannten offenen Schnittstellen auf der Basis einer 

15 objektorientierten SW-Technologie realisiert sind. 

3. Vermittlungsstelle nach Anspruch 1 oder 2, 
dadurch gekennzeichnet, dali 

die genannten offenen Schnittstellen auch lokal auf der 
20 kommerziellen Plattform von Applikationen verwendet werden 
konnen um Funktionen anderer Applikationen zu nutzen. 

4. Vermittlungsstelle nach einem der Anspriiche 1 bis 3, 
dadurch gekennzeichnet, dali 

25 ein dediziertes SW-Modul auf der kommerziellen Plattform das 
Interworking der genannten Applikationen unterstiitzt. Das 
,V1 Interworking SW-Modul stellt dafiir eine Plattf orm-interne 

* . Schnittstelle zur Verftigung, 

30 5. Vermittlungsstelle nach einem der Anspriiche 1 bis 4, 
dadurch gekennzeichnet, dali 
es sich bei den genannten Applikationen um 
Protokollumsetzungs-Applikationen handelt . 
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6. Vermittlungsstelle nach einem der Anspriiche 1 bis 4, 
dadurch gekennzeichnet, daB 

es sich bei den genannten Applikationen urn Applikationen fiir 
eine hoherwertige Dienstf unktionalitat handelt. 
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Zusammenf assung 

Programmierschittstellen zu einer Vermittlungsstelle 

Gemaft der Erfindung wird eine klassische Vermittlungsstelle 
mit einer zusatzlichen Plattform auf Basis kommerzieller 
Hardware und Software erganzt, auf der spezielle Module 
implement iert werden, deren Funktionen extern iiber offene 
Application Programming Interfaces (API) gesteuert werden 
konnen. Diese Plattform erlaubt so dem Netzbetreiber die 
Entwicklung eigener Telef onmehrwertdienste in einer 
kommerziellen Software Umgebung auf der Basis von APIs zu 
Vermittlungsstellenf unktionen . 



Figur 1 



